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Introduction 


Time  important  theoretical  underpinnings  of  computer  programming  are: 

(1)  Syntax.  Phrase-structure  grammars  (usually  context-free)  are  used  to  specify  the  form  programs  may  take  1 1 1. 
h  is  possible  to  give  very  precise  descriptions  using  more  complex  grammar  mechanisms  [2,3],  but  a  collection  of 
“static  semantics'*  informally  given  is  the  rule  [4],  In  any  case,  there  is  almost  no  disagreement  about  the 
appropriateness  of  defining  language  syntax  using  grammars. 

(2)  Semantics.  Meanings  can  be  assigned  to  programs  in  ways  ranging  from  clever  use  of  natural  language  [1] 
through  semi-formal  aids  [S]  to  careful  mathematical  definitions  [3,6,7],  Syntax  is  exploited  to  break  a  program 
into  units  whose  separate  meanings  are  defined,  then  combined  to  form  the  meaning  of  the  whole.  However,  there 
is  no  consensus  about  the  “best”  semantic  definitional  technique.  Furthermore,  it  is  easy  to  confuse  definition  with 
specification  (see  (3)  following)  because  each  technique  carries  with  it  a  natural  method  of  reasoning  about  the 
meanings  it  defines. 

(3)  Specification.  The  definition  of  programming-language  semantics  captures  what  a  program  does  mean; 
specification  captures  what  one  was  intended  to  mean.  It  is  natural  to  use  a  technique  for  specification  that  is 
closely  related  to  the  definitional  technique-then  it  is  possible  to  reason  about  programs,  that  is,  prove  things  about 
them  and  their  specifications. 

This  paper  describes  the  so-called  “functional  semantics”  of  Mills  [8,9],  which  combines  features  of  the  operational 
and  denotations!  approaches.  Care  is  taken  to  separate  definitions  of  semantics  from  specifications,  and  reasoning 
about  programs  from  both.  The  technique  is  both  intellectually  satisfying  and  practical. 

It  may  be  helpful  to  describe  our  goals  in  terms  of  the  best-known  alternative  semantic/specification  theory,  the 
Floyd/Hoare  assertion  technique.  (In  the  discussion  to  follow,  the  ideas  of  “truth”  and  “proof'  will  be  treated 
informally,  to  make  clear  the  computer- science  issues  at  the  expense  of  the  logical  ones.  For  a  complementary 
treatment,  see  Apt  [10].)  If  the  paper  were  explaining  the  Floyd/Hoare  technique  it  would  first  define  the  meaning  of 
the  syntactic  building  blocks  of  programs  (expressions,  assignments,  conditionals,  loops,  procedures,  etc.).  Since  the 
Floyd/Hoare  method  uses  assertions  in  a  first-order  theory  whose  syntax  overlaps  that  of  the  program,  these  meanings 
take  the  form  of  verification  conditions,  statements  built  for  a  language  construction  from  assertions  attached  before 
and  after  it.  The  verification  condition  for  (say)  assignment  VA  is  thus  a  definition  of  meaning:  given  pre-assertion  P 
and  post-assertion  Q,  VA(P,Q )  holds  just  in  case  the  truth  of  P  followed  by  execution  of  the  assignment  guarantees  the 
truth  of  Q. 

Specifications  for  the  Floyd/Hoare  method  consist  of  a  pair  of  assertions,  the  first  (input)  constraining  initial  values 
and  the  second  (output)  prescribing  final  values.  That  is,  the  desired  behavior  is  that  when  any  values  satisfying  the 
input  assertion  are  provided,  a  result  is  to  be  computed  that  will  satisfy  the  output  assertion.  (In  the  the  so-called 
“partial  correctness”  form,  the  result  need  only  satisfy  the  assertion  if  it  is  forthcoming.  This  is  obviously  a  poor  sort 
of  specification,  since  it  can  be  universally  met  by  a  nonhalting  program.) 

Finally,  with  both  semantics  and  specification  defined,  it  is  possible  to  reason  about  programs.  At  its  most  abstract, 
this  reasoning  takes  the  form  of  trying  to  devise  assertions  that  separate  each  program  construction  whose  meaning  has 
been  isolated.  With  given  input  and  output  assertions,  this  determines  all  the  verification  conditions,  and  proving  that 
each  is  true  establishes  that  die  program  meets  its  specification.  The  practical  application  of  the  Floyd/Hoare  method 
then  reduces  to  finding  appropriate  “intermediate  assertions”  to  go  with  a  program,  ones  which  lead  to  verification 
conditions  that  can  be  established.  In  many  cases  there  are  natural  choices  for  these  assertions,  choices  which 
guarantee  that  the  verification  conditions  are  true.  For  example,  if  the  assertion  before  an  assignment  is  the  same  as 
that  after  it,  but  with  the  assigned  expression  substituted  for  the  variable  assigned  to,  then  the  defining  verification 
condition  holds  and  need  not  be  considered  each  time. 

For  complex  constructions  of  a  programming  language,  the  necessary  intermediate  assertions  can  best  be  determined 
by  examining  the  program  and  trying  to  capture  in  an  assertion  just  what  is  in  fact  true  at  the  intermediate  point.  A 
substantial  component  in  establishing  verification  conditions  involves  not  their  form  arising  from  the  language 
definition,  but  their  inclusion  of  the  pre-  and  post-assertions.  Since  those  assertions  are  concerned  with  what  is  true  at 
a  point  in  a  program,  they  express  facts  about  program  values  and  operations.  In  this  way  much  of  a  program's  proof 
comes  to  be  concerned  with  its  subject  matter.  For  example,  number  theory  will  be  used  to  prove  programs  involving 
counting;  the  theory  of  permutations  will  be  used  in  sorting,  and  so  on. 

In  summary,  were  we  treating  the  Floyd/Hoare  method  we  would: 

(I)  Define  each  programming  language  construction  by  giving  its  verification  condition.  (The  “constructions”  are 
those  based  on  a  syntactic  decomposition  into  appropriate  units  sufficient  to  construct  all  programs.) 
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(2)  Define  specification  by  a  pair  of  input/output  assertions,  and  define  correctness  of  a  program  relative  to  a 
specification  as:  if  the  input  assertion  is  true,  the  program  must  execute  so  as  to  make  the  output  assertion  true. 

(3)  Describe  practical  methods  of  discovering  intermediate  assertions  so  that  the  task  of  establishing  that  a  program 
meets  its  specifications  is  simplified  and  mechanized  insofar  as  possible. 

(In  passing,  we  note  that  such  a  treatment  of  Floyd/Hoare  logic  is  not  easily  available.  Many  of  its  supporters  could 
supply  it,  and  it  could  be  obtained  from  die  literature  with  only  routine  (but  substantial)  work.  Nevertheless,  students 
of  computer  science  often  learn  the  method  without  much  understanding.) 

There  is  a  further  component  to  a  semantic  theory  that  we  do  not  intend  to  address  here,  which  for  the  Floyd/Hoare 
method  would  be  as  follows: 

(X)  Give  rules  for  design  and  construction  of  programs  to  given  specifications,  such  that  the  program  and  its 
assertions  (and  proof)  fit  together  naturally. 

This  final  step  is  the  most  difficult,  but  the  most  important  in  the  application  of  a  semantic  theory.  However,  it  is 
inessential  for  understanding.  It  is  quite  possible  to  have  a  satisfying,  revealing  explanatory  theory  about  the  world 
which  is  yet  difficult  to  apply  in  practical  cases.  In  this  paper  we  stress  analytic,  explanatory  ideas,  and  avoid  the 
ideas  of  synthesis.  It  is  not  that  our  theory  is  deficient  in  this  area.  To  the  contrary,  it  is  used  as  a  practical  design 
method  in  industry;  this  paper  deals  with  its  theoretical  underpinnings. 

The  rest  of  this  paper  is  organized  as  follows: 
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2  TIm  Language 


In  choosing  a  programming  language  to  explain,  when  the  subject  is  not  that  language  but  the  explanation,  there  is  a 
fine  line  between  the  real  and  the  abstract.  On  the  side  of  abstraction,  it  can  be  argued  that  the  language  should  show 
off  the  features  of  the  explanation  to  good  advantage,  and  the  peculiarities  of  real  languages  should  not  be  allowed  to 
confuse  a  clear  picture.  But  the  real-side  argument  is  equally  cogent:  if  the  explanation  cannot  easily  handle 
complications  that  exist  in  practice,  it  is  a  failure. 

As  primitive  data  types  we  include  only  character  data  and  files  of  characters.  The  virtue  in  this  choice  over 
numeric  types  is  that  it  eliminates  number  theory-not  die  central  language-theory  idea-from  the  example.  There  are 
few  natural  operations  on  characters,  but  comparisons,  and  the  operation  of  “next  in  alphabetic  sequence"  arc 
included;  the  latter  is  undefined  at  the  end  of  die  alphabet. 
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2  The  Language  3 

Statements  of  our  language  present  less  difficult  choices.  There  is  an  assignment,  read/write,  a  conditional, 
iteration,  and  procedure  invocation.  The  most  important  decision  here  is  to  allow  the  creation  of  intermediate  results 
through  assignment  (and  thus  deal  with  “sequential"  instead  of  “functional”  programming),  and  to  make  statement 
sequence  the  fundamental  construction  of  the  language. 

Declarations  must  be  treated  by  any  reasonable  semantic  theory,  but  block  structure  is  not  centra)  to  our  language. 
The  idea  of  two  identical  identifiers  with  different  meanings  is  retained  by  allowing  declared  procedures  to  have  local 
variables. 

Of  die  many  combinations  of  procedure  call  and  parameter  mechanisms,  we  have  chosen  call-by-reference  and 
recursive  procedures  as  the  ones  to  include. 

The  language  that  results  from  these  choices  is  probably  closer  to  1AL  (of  which  MAD  [11]  and  JOVIAL  [12]  are 
common  examples)  than  to  Pascal,  but  since  the  latter  is  much  better  known,  we  express  our  programs  in  a  subset  of 
Pascal  called  “OF  Pascal”  (for  Character,  Hie).  Although  for  present  purposes  it  is  irrelevant  that  this  language  is  of 
practical  use,  we  have  found  it  so  for  text-formatting  problems,  and  for  teaching  introductory  programming  [13].  The 
exact  scope  of  the  CF  subset  is  best  defined  by  the  semantics  to  follow:  CF  Pascal  includes  what  we  define,  and 
where  the  Pascal  definition  [14]  is  clear,  we  define  it  that  way. 


3  Functions  and  Data  States 


CF  Pascal  programs,  viewed  as  “black  box”  objects,  have  two  special  files,  input  and  OUTPUT;  a  program 
transforms  the  former  into  the  latter.  Because  these  files  contain  character  sequences,  the  meaning  of  a  program  is  a 
siring-to- string  mapping.  It  is  the  “denotational”  view  of  semantics  (usually  credited  to  Scott  [IS])  to  assign  to  a 
program  text  (itself  of  course  a  string)  a  meaning  from  die  string-to- string  maps,  and  to  construct  this  meaning  by  first 
assigning  appropriate  mappings  to  program  ports,  then  combining  them  into  a  meaning  for  the  entire  program.  To  the 
contrary,  in  the  “operational”  view  (which  goes  back  at  least  to  Turing  [16])  of  semantics,  the  central  role  is  played 
by  an  internal  program  state,  and  the  parts  of  the  program  are  viewed  as  authorizing  transformations  of  that  state.  The 
program’s  function  is  then  die  collection  of  all  pairs  that  begin  and  end  a  transformation  sequence  called  a 
“computation.” 

The  semantic  theory  to  be  presented  here  uses  both  ideas.  We  make  essential  use  of  an  internal  state  and  its 
transformation,  but  we  express  the  state-to-state  maps  denotationally  instead  of  speaking  about  computation  sequences. 
The  result  combines  the  low-level,  step- by-step  intuition  of  the  Turing  approach  with  the  clarity  of  Scott's  overall, 
functional  view. 


3.1  TIm  CF  Pascal  Data  State 


With  only  characters  and  files  of  characters,  the  values  associated  with  quantities  internal  to  CF  Pascal  programs  come 
from  an  alphabet  and  strings  over  that  alphabet,  with  the  complication  that  files  are  “marked”  to  separate  the  part 
already  processed  from  that  yet  to  be  processed.  That  is,  a  file  is  technically  a  pair  consisting  of  a  “past”  string  and  a 
“future”  string.  Thus  a  data  state  of  a  CF  Pascal  program  includes  values  from  the  two  sets:  characters  and  string 
pairs.  Each  value  is  connected  with  a  program  identifier,  and  represents  its  current  “contents.”  In  the  denotational 
view  a  data  state  is  therefore  a  mapping  from  identifiers  to  values.  For  example,  in  a  program  where  the  identifier 
OUTPUT  (of  type  text)  and  xxx  (of  type  chap)  occur  (note  the  special  type  font  employed  for  parts  of  programs), 
a  data  state  T  might  be: 

T  »  {(OUTPUT, (Psp  *1.  A)),  (XXX.2)} 

where  strings  such  as  Ptga  1  are  shown  in  a  special  type  font,  and  A  is  the  empty  string.  However,  when  no 
confusion  can  arise,  we  will  display  data-state  examples  in  a  simpler  notation,  using  the  type  fonts  to  distinguish 
values  from  identifiers.  For  example,  the  data  state  T  above  will  be  written: 

T  -  (OUTPUT*  Pvp  xxx*2) 
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where  the  “*”  separates  identifier  and  value,  and  an  underline  marks  the  first  character  of  the  future  string  in  a  file. 
In  the  example,  output’s  future  string  is  empty.  As  an  example  of  the  denotational  view,  in  which  T  is  a  mapping, 
we  would  write  in  this  case: 

T(xxx)  =  , . 

To  express  the  transformation  of  one  data  state  to  another,  our  notational  device  is  to  employ  the  program  fragment 
that  effects  the  transformation,  but  to  distinguish  that  fragment  from  a  string  (the  program  syntax)  by  surrounding  it 
with  a  box.  (The  idea  is  due  to  Kleene  [17].)  Thus  the  denotational  view  that  the  meaning  of  a  fragment  is  a 
mapping,  and  meaning  itself  the  association  of  a  program  string  with  its  data-state  map,  is  expressed  by  boxing  the 
string  and  being  explicit  about  the  state.  For  example,  in  the  state  T  above,  the  transformation  effected  by 

WR I TE  t ' 3 ' J 

would  be  shown  as 

1  WRITE!  '3' 7  1  (T)  =  (OUTPUT* !i_,  XXX*2). 

The  notation  is  excellent  for  expressing  examples;  when  we  try  to  give  the  general  case  (for  example  if  T  were  not  a 
particular  data  state,  but  any  state)  it  works  less  well.  The  functional  notation  using  ordered  pairs  is  an  improvement. 
For  this  example, 

1  WR  i  TE  t 1 3 '  1  [  =  {(7~,  U):T  =  U  except  that  the  past  string  of 
{/(OUTPUT)  is  the  past  string  of 
/(output)  with  3  appended}. 


3.2  Meaning  of  Expressions 

The  meanings  of  CF  Pascal  statements  and  programs  are  constructed  from  the  meanings  of  CF  Pascal  expressions. 
Because  the  language  is  severely  restricted,  there  are  very  few  of  these.  The  meaning  of  an  expression  is  a  mapping 
from  data  states  to  the  appropriate  value  range  (characters  for  CHAR  expressions,  string  pairs  for  files,  and  {true,  false} 
for  Boolean  expressions).  If  X  is  a  variable  (necessarily  of  type  CHAR  or  text),  then 

\m  (D  =  T(X). 

For  example,  if 

T  -  (OUTPUT*  \ af r5  _,  XXX*i) 
then 

I  output  |  (D  =  Pamt  'j 
XXX  |  (T)  =  k. 

(The  file  notation  does  not  distinguish  a  blank  future  string  from  an  empty  one;  rather  than  introduce  a  visible  “blank" 
character,  we  will  avoid  blanks  in  examples  where  they  would  cause  trouble.) 

The  constants  in  CF  Pascal  are  of  type  char,  and  their  meanings  are  the  obvious  ones: 


3.2  Meaning  of  Expressions 
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f  »A»'i(n  =  * 
PbH  ( T)  =  -i 
etc. 


for  all  data  states  T. 

The  only  other  CHAR  expression  uses  the  built-in  function  SUCC,  and  its  meaning  is  defined  inductively.  As  a  first 
attempt,  we  might  try: 

I  8UCC(El~~l  (T)  =  the  character  following  |  £  1  (T) 
in  sequence, 

where  E  is  any  CHAR  expression,  and  “in  sequence”  is  the  lexicographic  character  ordering  defined  for  Pascal. 
Because  die  character  ordering  may  differ  from  machine  to  machine,  and  to  illustrate  the  treatment  of  runtime  errors, 
we  here  take  SUCC  to  be  defined  on  &  through  T  in  the  obvious  way,  but  make 

I  succt  ’z’  jTJ 

undefined  for  all  data  states.  This  statement  could  be  added  to  the  English  of  the  trial  definition  above,  but  instead 
we  move  the  data  state  into  the  defining  condition,  and  give  the  meaning  function  itself  as  a  collection  of  ordered 
pairs: 

f  SUCCtE]  |  =  {(T,  c ):  [T]  (T)  is  the  character  b, 
and  c  follows  b  in  sequence}. 

In  this  definition,  |  SUCCtEl~1  can  fail  to  be  defined  at  a  particular  input  state  T  for  two  reasons.  It  may  happen  that 
I  E  |  is  not  defined  at  T  (and  hence  |  E  \  (T)  is  no  character  b  as  required),  or  that  b  has  no  following  character  c.  In 
either  case,  this  T  never  appears  paired  with  any  c  in  die  defining  set. 

Finally,  Boolean  expressions  can  be  given  meaning.  Only  single  comparisons  between  character  expressions  are 
part  of  CF  Pascal,  and  the  definitions  all  have  the  form: 

nr<~f  I  (D  =  true  if  \~E]  (T) 

precedes  \  F  1  (D;  false  otherwise 

for  all  expressions  E  and  F  (and  similarly  for  the  operators  other  than  <).  In  contrast  to  the  treatment  of  SUCC,  we 
here  assume  that  each  pair  of  characters  can  be  meaningfully  compared,  but  only  obvious  situations  like  §  <  1  will 
occur  in  examples.  Care  is  required  here  because  of  the  occurrence  of  the  box  functions  on  the  right  side  of  the 
definition.  Should  one  of  them  be  undefined,  then  the  meaning  function  of  the  Boolean  expression  is  also  undefined. 
This  corresponds  to  the  Pascal  convention  of  complete  evaluation  (as  opposed  to  McCarthy  evaluation)  of  Boolean 
expressions,  and  to  die  arbitrary  choice  that  once  a  runtime  error  occurs,  the  failure  of  meaning  propagates.  Failure  to 
be  careful  about  such  definitional  matters  has  long  been  a  source  of  trouble  in  program  proving  [18]. 

The  definition  of  meaning  for  CF  Pascal  expressions  is  now  complete. 
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3.2  Meaning  of  Expressions 


3.3  External  Strings  and  Data  States 


The  meaning  of  a  program  must  be  a  string-to-string  function;  the  meaning  of  a  program  fragment  is  a 
data-state-to-data-state  function.  To  bring  these  into  line  requires  associating  a  string  that  is  presumed  to  constitute  the 
input  file  with  an  appropriate  internal  data-state  string  pair  attached  to  l  nput,  and  similarly  associating  the  internal 
OUTPUT  pair  (initially  empty  in  both  past  and  future  parts)  with  die  program  output.  The  necessary  actions  can  be 
imagined  to  be  the  meaning  functions  of  the  program  header  and  terminating  period,  program  parts  that  therefore 
transform  strings  to  states,  and  states  to  strings,  respectively. 

[program  P  t  input,  output!-! (D) 

=  ( I  NPUT*D,  output*  ) 

m  (  ....  OUTPUT *Z)_,  ...)  =  D 

where  D  means  the  empty  string  A  paired  with  D:  (A,  D),  that  is,  D  with  its  first  character  marked;  and  D  means  the 
string  pair  (D,  A),  that  is,  D  with  the  mark  on  an  empty  string  following  its  last  character. 


3.4  Calculating  Program  Moaning 


The  semantics  to  be  presented  below  is  a  functional  '‘calculus”  that  allows  step-by-step  computation  of  a  program’s 
meaning.  By  anticipating  some  of  the  definitions  to  be  subsequently  presented,  we  can  now  illustrate  this  calculus. 
For  the  purposes  of  illustration,  the  following  are  special  cases  which  will  appear  later  in  more  general  form: 


BEGIN  END 


=  / 


|  BEGIN  IF  E  THEN  end!  =  {(T,  T):  [T]  is  defined  at  J) 

where  /  is  the  identity  function.  (In  die  second  case  the  function  is  either  /  or  a  subfunction  of  /  defined  just  where 
I  E  |  is  defined.)  A  program’s  meaning  is  defined  to  be  the  (functional)  composition  of  the  meanings  of  its  fragments, 
taken  in  order.  Then  we  can  calculate: 


I  PROGRAM  PHINPUT,  OUTPUT);  BEGIN  END. 


(D) 


-  |  BEGIN  END.  1  (  |  PROGRAM  PI  t  INPUT.  OUTPUT)  1  (£>)) 


(meaning  of  die  program  is  the  composition  of  its  parts’  meanings) 
-  I  BEGIN  END.  1  (( I NPUT*f>,  OUTPUT*  )) 


(definition  of  the  meaning  of  the  header) 

-  m  (  I  BEGIN  END  1  ((INPUT*D,  OUTPUT*  ))) 

(composition  of  parts  again) 

-  |  .  1  (/(( I  NPUT*P,  OUTPUT*  ») 

(die  meaning  of  the  null  statement  is  the  identity  function  /) 
«  m  (( I  NPUT*P,  OUTPUT*  )) 

(by  definition  of  I) 


-  A 


(definition  of  the  meaning  of  the  final  period). 
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=  fT~l  (  I  BEGIN  .  .  .  END~|  ((INPUT*!?,  OUTPUT*  )» 

(as  above). 

The  function 

I  BEGIN  IF  BUCCt'Z')  <  'A'  THEN  END  | 

is  by  definition  either  the  identity  function  or  undefined,  depending  on  the  evaluation  of  the  two  char  expressions. 
Both  have  (or  fail  to  have)  values  independent  of  the  Mate,  namely 

I  SUCCt  'Z'  l  I  (D  ~  character  following  I  '2'  |  (T)  (if  any) 

-  character  following  2  (if  any) 

but  in  fact  there  is  none.  It  is  therefore  irrelevant  that 

m  (D  =  A; 

the  inner-most  function  is  undefined,  and  the  result  is  that  the  program  PS  means  a  function  that  is  everywhere 
undefined,  that  is,  die  empty  function. 


A  I  Inammai  BMamMaaa* 
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This  section  includes  the  definitions  of  meaning  for  each  imperative  statement  of  CF  Pascal,  by  subsection: 


Subsection 

Program  part 

4.1 

Nidi  statement 

4.2 

Variable  declaration 

4.3 

Assignment  statement 

4.4 

Statement  sequence 

4.5 

WRITE  statement 

4.6 

READ  statement 

4.1  Null  Statmut 


Although  the  null  statement  often  only  enters  programs  by  accident,  it  is  a  legitimate  part  of  CF  Pascal.  The 
statement  “does  nothing,”  which  means  that  whatever  date  state  exists  before  its  execution  is  unchanged  afterwards. 
The  function  with  this  behavior  is  the  identity  /.  Thus  define: 


4.2  Variable  Declarations 


The  declarations  within  a  program  have  a  role  in  the  program  calculus  similar  to  that  of  the  program  header:  they 
modify  the  data  state  so  that  it  contains  the  proper  identifier  names  for  the  remainder  of  the  program  to  process.  Each 
VAR  declaration  has  a  functional  meaning  that  transforms  a  data  state  in  which  its  identifier  does  not  appear,  to  one  in 
which  it  does  appear.  Here  we  have  another  choice  to  make:  what  value  should  be  associated  with  such  a  new-made 
identifier,  and  what  are  the  rules  for  using  this  value?  In  some  Pascal  implementations,  a  special  value  that  cannot  be 
confused  with  any  other  is  attached  to  newly  declared  identifiers,  and  this  value  cannot  be  referenced  without  a 
machine  trap,  so  the  variable  must  be  overwritten  between  declaration  and  reference.  It  is  more  common  to  attach  an 
arbitrary  value  to  declared  identifiers  until  they  are  overwritten  (often  the  left-over  contents  of  memory  previously 
used)~such  a  value  can  be  used,  with  unexpected  results.  It  seems  clear  that  we  should  adopt  the  former  view:  use  of 
a  newly  declared  identifier  is  a  run-time  error  until  it  has  been  given  a  value. 

The  effect  of  a  VAR  declaration  is  to  extend  the  domain  of  the  identifier-value  map  to  include  a  new  identifier.  To 
reflect  the  possibility  that  any  value  might  be  subsequently  acquired,  we  define  the  meaning  of  the  declaration  to  be  a 
relation  including  all  values  of  die  appropriate  kind.  That  is, 

I  VAR  V:  K  I  ={(T,ff):W=ru 

{(V,  jc):  x  is  a  value  of  type  K)  }. 

This  relation  in  which  all  possible  values  are  paired  with  V  is  awkward  to  write,  so  we  introduce  a  shorthand  of  “?” 
(not  the  character  1,  as  the  typography  shows)  for  the  multiple  values.  Then  for  example  the  program  part 

VAR  Fraah:  CHAR 
transforms  execution  state 


( i  nput*M€,  output*) 


to  execution  state 


( I  NPUT*M®,  OUTPUT*  .Freeh*?). 


In  the  box  notation: 


I  VAR  Freeh:  CHAR  |  ( I NPUT*M€,  OUTPUT*_) 

*  (INPUT*/pS,  OUTPUT*_,  Freeh*?) 

The  declaration  of  multiple  variables  requires  an  obvious  extension  of  this  definition. 

When  a  data  state  is  not  a  function  because  in  it  some  identifier  V  is  associated  with  all  potential  values  (in  the 
shorthand,  die  state  contains  (V*?)  ),  then  the  expression  V  has  a  meaning  that  is  the  undefined  function.  That  is,  in 
this  case  I  V  1  is  undefined  for  all  states. 


4.3  Assignment  Statements 


The  intuitive  meaning  of  the  assignment  statement  as  a  data-state  transformation  is  that  the  identifier  on  the  left  side 
ceases  to  be  associated  with  its  old  value,  and  instead  becomes  associated  with  a  value  obtained  from  the  right  side. 
In  CF  Pascal,  assignment  statements  are  of  the  restricted  form: 

V  :=  E 

where  V  is  a  variable  declared  as  CHAR  and  E  is  either  a  variable  declared  as  char  or  a  literal  character  enclosed  in 
single  quotation  marks,  or  a  nest  of  SUCC  function  calls  founded  on  such  a  variable  or  literal.  Section  3.2  has 
formally  defined  the  box  function  for  such  expressions  as  a  mapping  from  data  states  to  character  values  (which  may 
be  undefined  for  some  uses  of  SUCC).  The  investment  in  notation  now  pays  off  in  a  concise  definition  of  the 
meaning  of  an  assignment  statement: 

I  V  ;  =  £  |  =  {(T,  U):  V  is  the  same  data  state 
as  T  except  that  U(V)  =  [  E  |  (7)}. 

As  usual,  the  definition  includes  the  implicit  case  that  should  |  E  1  be  undefined,  then  so  is  the  assignment-statement 
function  undefined.  The  failure  in  not  in  the  theory’s  definition  of  meaning  (the  box  function):  the  box  function  is 
defined,  to  be  the  everywhere-undefined  function. 

Here  are  four  examples: 


1  VI 

=  'c'  |  ((vi *A,  V2*®))  =  (vi*(£,  va*a), 

|  V2 

=  VI  |  ((VI  *1,  va*l)  =  (VI  V2*£*i), 

1  vi 

=  succtvi)  |  is  undefined  on  the  state  (Vi *1 

[  va 

=  va  |  is  undefined  on  the  state  (va*?). 

4.4  Statement  Sequences 


The  fundamental  rule  of  the  program  calculus  is  functional  composition.  To  calculate  the  meaning  of  a  sequence  of 
CF  Pascal  constructions,  first  obtain  the  functional  meaning  for  each  one,  then  compose  those  functions.  In  many 
cases,  constructions  are  separated  by  a  semicolon  so  we  can  write: 

i  s,;  &  kd=  r&ri  ( ixi  (D), 

or  in  the  purely  functional  notation, 

r  s,;  s2 1  =  I~s71  *  \~Ti  1  , 

where  *  indicates  composition. 

The  keywords  BEGIN  and  ENO  are  used  to  group  statement  lists  in  Pascal.  Within  these  lists  there  may  be  a 
number  of  statements  (or  none).  But  except  for  the  grouping,  there  is  no  meaning  attached  to  the  BEG  I  n-end  itself. 
Its  meaning  is  the  meaning  of  what  occurs  within  it.  Thus: 

f  BEGIN  L  ENO  |  =  |T] 


where  L  is  a  list  of  statements. 
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4.4  Statement  Sequences 


There  is  here  (and  above  is  less  obvious  cases)  a  lack  of  precision  caused  by  omitting  detailed  syntactic  analysis. 
Presented  with  a  block  of  program  text  surrounded  by  a  box.  how  is  the  text  to  be  broken  up  into  units  to  which  the 
definitions  are  applied?  We  have  used  words  like  “expression”  and  “statement”  and  “declaration”  as  if  they  had 
precise  meaning  in  any  such  text.  And  of  course,  if  care  were  used,  they  do  have  precise  meaning,  given  by  the 
derivation  tree  for  the  program.  In  that  tree  at  any  level  there  is  precisely  one  “expression,”  etc.,  indicated  by  the 
nonterminal  of  that  name  in  an  appropriate  CF- Pascal  grammar.  This  use  of  grammar  as  a  basis  for  the  semantics 
goes  back  to  ALGOL  60  (1],  and  may  be  the  most  important  feature  of  grammar-based  syntax.  Here  we  do  not  make 
the  correspondence  very  precise,  but  in  examples  we  order  the  compositions  as  they  appear  in  the  derivation  tree. 


4.5  WRITE-Statwiwnts 


Whatever  a  program  may  do  internally  to  its  execution  state,  the  result  cannot  be  observed  by  a  person  unless 
WRITE-statements  are  included  to  communicate  the  internal  state  to  the  outside  world.  In  CF  Pascal,  a 
WRITE-statement  may  include  only  a  sequence  of  expression  arguments  (of  the  kind  defined  in  Section  3.2).  With 
this  restriction,  each  argument  has  a  box  function  already  defined.  The  meaning  of  the  statement  can  then  be  given  in 
terms  of  these  components  in  die  natural  way:  a  WRITE-statement  appends  to  the  special  identifier  OUTPUT  in  the 
data  state  the  character  values  of  its  argument  items,  in  order. 

Let  a  WRITE-statement  have  arguments  Et,  £2,  ...  in  order.  For  execution  state  T,  form  the  values: 

Vt  -  □□  (D.  V2=  [£[]  (T).  ... 

Then  the  value  attached  to  output  in 

I  WRlTEtEi,  El.  ■■■)  I  (T) 
is  7XOUTPUT)  with  V,  and  V2  and  ...  appended  in  order. 

Enough  of  the  program  calculus  has  now  been  presented  to  handle  the  very  simplest  complete  programs.  For 
example,  if  P  is: 

PROGRAM  WriteHe  Mot  INPUT,  OUTPUT): 

VAR 

LattarL:  CHAR; 

BEGIN 

LattarL  :=  'L': 

WRITEC'H',  'E'.  LattarL,  LattarL,  'O') 

END. 

then  if  the  input  string  is  *  the  program  header  and  vap  declaration  establish  the  state 
(  I  NPUT**,  OUTPUT*  ,  LattarL*?) 
on  which  the  program  works  as  follows: 


IWRITEt'H1.  'E*.  LattarL,  LattarL,  'O' H 
(  I  LattarL  :  *  'L'~l 

((INPUT**,  OUTPUT*  ,  LattarL*?))) 

*  1  WRITE! 'H',  'E1,  LattarL.  LattarL,  ’O')  I 

((INPUT**,  OUTPUT*  .  LattarL*!)) 

by  die  action  of  the  assignment  statement  and  statement  composition.  The  values  of  the  arguments  in  the 
WRITE-statement  are: 


4.5  WRITE-Statements 
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I  ’H1  1  (( I  NPUT**,  OUTPUT*_,  L*tterL*l)  =  IK! 

I  'E1  |  ((INPUT**,  OUTP(JT*_,  LetterL*i)  =  E 
1  Lettanll ((INPUT**,  £XJTPUT*_,  L.atterL*l)  =  IL 
j  'O’  |  ((INPUT**,  QUTPUT*_,  LettarU*i)  =  0 

The  WRITE-statement  thus  changes  the  execution  state  to: 

( I NPUT**,  OUTPUT*[ffilX0_,  Lettarl-*i) 

and  the  final  action  of  the  .  following  end  is  to  produce  the  meaning  of  program  P: 

|  P  |  (y)  =  ME110  for  any  y. 


4.6  READ-Statoments 


The  list  of  arguments  in  a  CF  Pascal  READ-statement  can  consist  only  of  identifiers  declared  as  CHAR  variables. 
READ-statement  meaning  is  easy  to  give  if  enough  characters  are  available  in  the  data  state  (i.e.,  attached  to  i  NPUT 
as  future  string).  However,  should  there  be  too  few  characters,  the  READ-statement’s  meaning  function  goes 
undefined.  The  case  of  multiple  variables  in  a  READ-statement  is  a  straightforward  extension  of  the  single-variable 
case. 

Suppose  then  that  a  data-state  value  for  I  NPUT  contains  at  least  one  character  in  its  future  string,  say  c.  In  the 
abbreviated  form  of  a  data  state,  write  such  a  value  as 

input**  cy 

where  *  and  y  represent  the  parts  (if  any)  of  the  value  not  of  interest.  (*  is  the  past  string;  die  future  string  begins 
with  c  and  ends  with  y.)  Then  die  meaning  of 

REAOCCvl J 

where  the  variable  is  suitably  declared  CHAR  is 

1  REAO(Cvl)  |  ((INPUT**cy,  ...,Cv1*v,  ...)) 

=  (INPUT**C£,  ...,Cv1*C,  ...) 

where  the  division  point  between  the  past  and  future  strings  for  I  NPUT  now  occurs  just  before  y. 

As  an  example,  consider  the  program  P: 

PROGRAM  ChangnSt INPUT,  OUTPUT); 

VAR 

CS:  CHAR; 

BEGIN 

READ CCS); 

WRITE CCS) ; 

REAO(CS) ; 

WRITE! 'S' ) 

END. 


We  work  out: 
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4.6  READ-Statements 


The  program  header  and  the  var  declaration  establish  the  execution  state: 

(  I  NPUT*ptC,  OUTPUT*_,  C2*?). 

Then  the  successive  statements  yield: 


I  READ t Cg 3 ;  WRITECCg);  READ t CS 3 ;  WRITEC'g1)  | 

(( INPUT*ip£,  OUTPUT*_,  Cg*?)) 

=  |  WRITEIC2) ;  READ (Cg) ;  WRITE! 'g' 3  | 

(( I  NPUT*A|lG,  OUTPUT*-,  C2**)) 

=  1  READ t Cg 1 ;  WRITE! 'g')  | 

((  I  NPUT*Ml£,  OUTPUT*^!-,  C2=A)) 

=  |  WRITEt  'g*  1  |  (( I NPUT*A®E,  OUTPUT**-,  C2*i)) 

=  ( i  nput**!<£,  output**2_,  C2*l). 

The  final  .  yields: 

f T1  (ADty  =  IH£. 

Reading  past  end  of  file  is  a  runtime  error  in  CF  Pascal,  so  in  the  definition  we  must  exclude  those  data  states  in 
which  there  are  insufficient  characters  on  the  future  string  attached  to  i  nput.  Define: 

|  REAO(CT~l  =  {(7\  U ):  the  first  character  of  the  future 
string  in  7X I  NPUT)  is  c,  and  U 
is  the  same  as  T  except  that  (i)  c 
is  transferred  to  the  end  of  the  past  string 
in  U{  i  nput)  and  (ii)  U(C)  =  c}. 

As  usual,  note  the  failure  of  definition  expressed  by  there  being  no  fust  character  as  required,  and  hence  no  ordered 
pair  in  the  defined  function  with  this  property. 


4.7  File  Input-Output 

CF  Pascal  acquires  its  power  from  the  use  of  intermediate  files  which  may  be  written  and  then  read  back.  For 
example,  sorting  can  be  accomplished  by  separating  the  input  into  multiple  streams  which  can  then  be  merged.  For  a 
variable  Fv  of  type  TEXT  the  statements 

WRITElFv.  .  .  .  ) 

READCFv,  . . . ) 

act  as  those  defined  above,  but  on  the  file  Fv  instead  of  OUTPUT  and  input.  There  is  considerable  complexity 
introduced  by  this  extension,  because  files  must  be  properly  initialized  with 

REWRITEtFv) 

for  (overwriting,  and 

RESET [Fv 3 

for  (re)reading.  The  ability  to  specify  a  file  name  raises  the  possibility  of  numerous  runtime  errors,  for  example, 
trying  to  read  a  file  that  is  being  written,  without  using  RESET.  To  handle  these  complications  requires  adding 
information  to  the  pair  of  strings  that  is  a  data-state  file  value,  namely  a  “mode"  tag  for  read/write  status.  File  values 


4.7  File  Input-Output 
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are  then  triples  consisting  of  the  past  and  future  strings  and  the  mode  tag.  The  meaning  of  REWR  t  te  and  reset, 
and  the  changes  to  the  meaning  of  wn  I  TE  and  READ  can  then  be  given  in  a  straightforward  way.  Since  we  will 
not  here  analyze  programs  using  file  input-output,  these  definitions  are  omitted. 


4.8  Analysis  of  Linear  Programs 

The  examples  of  this  section  have  shown  that  given  a  linear  program  and  any  particular  input  string,  the  calculation 
of  the  resulting  output  string  (if  any)  is  a  straightforward,  mechanical  process.  It  is  a  little  more  difficult  to  begin 
with  the  program  alone,  and  calculate  the  function  it  means.  The  difficulty  is  one  of  notation,  since  the 
set-theoretic  definition  of  the  meanings  of  program  parts  can  be  difficult  to  combine  concisely.  We  mention  one  of 
several  techniques  that  are  useful  in  practice,  the  trace  table  (9).  This  device  can  be  applied  to  any  series  of 
assignments,  and  amounts  to  a  symbolic  execution  of  the  program.  A  tabular  sequence  of  equations  is  created,  in 
which  subscripted  versions  of  die  variables  appear,  defined  in  terms  of  earlier  such  variables.  The  set  of  equations 
can  be  solved  for  final  variable  values  in  terms  of  the  initial  ones.  For  example,  the  program  fragment 


BEGIN 

VI 

=  V4; 

V2 

*  V3: 

V3 

*  V2: 

V4 

=  VI 

END 


cannot  be  understood  directly  without  some  effort,  but  yields  easily  to  the  trace-table  method: 


VI 

V2 

V3 

V4 

VI 

:  =  V4; 

VI,— V4„ 

V2,=V2o 

V3,*V3o 

V4,=V4o 

V2 

:=  V3; 

Vlj=Vl, 

V22=V3, 

V32=V3, 

V42=V4, 

V3 

:=  V2; 

Vlj=Vl2 

V23=V22 

V33=V22 

V43=V42 

V4 

:  =  VI 

V14=V13 

V24=V23 

V34=V33 

> 

II 

♦ 

> 

These  subscripted  variables  are  of  the  usual  mathematical  sort,  not  the  program  sort;  that  is,  they  represent  fixed 
unknowns,  and  the  set  of  equations  can  be  solved  by  repeated  substitution: 

Vl4  *  Vl3  =  Vl2  =  VI,  =  V4o 
V24  *  V23  =  V2j  =  V3|  =  V3o 
V34  -  V33  *  V22  =  V3,  =  V30 
V44  *  VI,  =  VI,  =  VI,  *  V4o 

That  is,  collecting  these  results: 

Vl4  *  V4o,  V24  -  V3o,  V34  =  V3o,  V44  =  V4o 

The  analysis  has  shown  that  the  program  above  has  the  same  effect  as 

BEGIN 

VI  :*  V4; 

V2  : =  V3 
END 

which  may  be  a  surprise  to  the  programmer. 


5  Correctness 


Any  program  has  a  purpose,  but  that  purpose  may  not  require  results  in  some  exact  form.  For  example,  a  program 
may  be  required  to  print  the  members  of  a  set,  without  their  order  or  the  page  layout  being  specified.  These 
variations  can  be  described  by  providing,  for  each  instance  of  input  data,  a  set  of  acceptable  instances  of  output 
data.  The  description  is  a  relation  consisting  of  all  pairs  of  acceptable  instances  of  input  data  and  output  data. 
Therefore,  a  program  specification  is  defined  as  any  relation  whose  domain  and  range  are  sets  of  character  strings. 

lust  as  a  program  function  may  be  difficult  to  describe  in  a  well-known  mathematical  form,  but  nevertheless 
exists  for  every  program;  so  a  program  specification  may  be  difficult  to  set  down,  but  is  a  mathematical  relation 
nevertheless. 

An  important  special  case  of  a  specification  occurs  when  the  acceptable  pairs  of  input  data  and  output  data  form  a 
function;  that  is,  for  each  instance  of  input  data  exactly  one  instance  of  output  data  is  acceptable.  This  special  case 
of  a  specification  relation  is  therefore  a  specification  function. 

The  specification  (relation  or  function)  for  a  program  is  a  mathematical  form  of  what  the  program  is  supposed  to 
do,  a  description  of  desired  results.  This  form  is  entirely  independent  of  any  program  to  realize  it,  and  in  fact  is 
the  starting  point  for  writing  a  program.  It  is  important  to  recognize  that  a  specification  gives  no  information  about 
how  some  program  might  perform  to  meet  it.  Since  it  is  simply  a  collection  of  input-output  pairs,  it  states  what  is 
to  be  done,  without  a  hint  of  a  method  for  doing  it.  On  the  other  hand,  once  a  particular  program  exists,  its 
program  function  (which  is  the  same  kind  of  mathematical  object  as  a  specification  function)  defines  what  the 
program  does  do,  without  regard  for  any  intentions  the  programmer  may  have  had.  Furthermore,  using  the  program 
calculus,  this  meaning  can  be  calculated  step-by-step  from  the  program  text  itself.  The  program  function  itself  does 
not  express  how  the  program  accomplishes  what  it  does,  but  to  calculate  the  program  function  requires  full  details 
of  the  program’s  inner  workings.  A  central  question  of  programming  can  be  simply  stated  in  these  terms: 

Given  a  specification  and  a  program,  does  the  program  fulfill  that  specification? 

The  technical  definitions  necessary  to  stale  this  question  are  already  available.  Given  a  program  specification 
relation  r  and  a  program  P,  we  say  that  P  is  correct  with  respect  to  r  if  and  only  if,  for  every  member  x  of  the 
domain  of  r  (an  instance  of  input  data),  P  produces  some  member  of  the  range  of  r  which  is  paired  with  x  in  r.  That 
is,  for  each  input  x,  P  produces  result  y  such  that  (r,  y )  «  r. 

Theorem  (Program  Correctness) 

Program  P  is  correct  with  respect  to  specification  relation  r  if  and  only  if: 
domain(r  fl  |  P  | )  =  domain(r) 

Proof  The  expression  r  fl  |  P  |  identifies  all  acceptable  pairs  of  r  computed  by  P.  Therefore  domain(r  fl  |  P  ]  ) 
identifies  the  set  of  input  data  for  which  P  produces  acceptable  output  data.  Since  domain(r)  is  the  set  of  input  data 
for  which  r  specifies  acceptable  output  data,  the  condition 

domain(r  fl  |  P  1 )  *  domain(r) 

ensures  that  P  produces  acceptable  output  data  for  every  instance  of  input  data  defined  by  r.  QED 

Note  that  P  may  execute  successfully  for  input  data  not  identified  by  r,  but  such  pairs  of  |_P_j  are  screened  out  of 
(r  fl  |  P  |  )  by  r.  Note  also  that  if  P  produces  an  unacceptable  instance  of  output  data,  no  member  of  r  with  that 
input  data  can  be  in  (r  fl  |  P  | ),  and  therefore  domaiiHr  fl  |  P  1 )  cannot  coincide  with  domain(r). 

In  case  the  program  specification  is  a  function,  the  condition  for  program  correctness  can  be  simplified  as  follows: 

Corollary  (Program  Correctness) 

Program  P  is  correct  with  respect  to  specification  function/  if  and  only  if 

/c  CD- 

Proof  The  expression  /  fl  |  P  |  identifies  all  acceptable  pairs  of  /  computed  by  P,  which  must  be  /,  itself.  That  is.  P 
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is  correct  with  respect  to/if  and  only  if 

/n  [T]  -/. 

— d  that  if  md  only  if  / C  [T| .  QED 


ch  of  the  power  (and  complication)  in  programs  cooes  from  their  conditional  statements,  which  provide  the  means 
!««■!  decisions  bated  not  only  on  program  input,  but  on  intermediate  values  internal  to  the  program.  However, 
nw«ing  of  a  gjogle  conditional  in  isolation  is  easy  to  define. 


6.1  M— nlng  of  CondMonal* 


Let 


5 


*  if B 
THEN 
T 

ELSE 

£ 


where  B  is  a  Boolean  expression  and  T,  E  are  statements.  Then 


□3  do- 


CF] «/)  if  [T](i/) 

«  r  ji  do  g  ~  in  do 

otherwise  [T]  “  **  defined  at  U. 


For  example  if 


St  -  if  vi  <  va 

THEN 

VI  :*  va 

ELSE 

va  : *  VI 


Then 


I  Si  I  ((vi*A,  va*B)>  -  (vi  *1,  va*B) 


(23  ((vi  *A,  va* B))  -  true, 
ffl  ((vi va**))  -  (vie*.  va*B), 

and  the  value  of  I  ill  for  this  data  stale  is  given  by  the  value  of  [T]  . 

la  older  to  give  a  definition  by  cases  without  explicitly  naming  the  data  state,  it  is  necessary  to  select  one  of  two 
sets  of  ordered  pain  according  to  the  Boolean  expression.  The  following  standard  trick  accomplishes  this: 
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1X1  =  {< v ,  JT]  m-.  [XI  ((/>} 

U  {(l/,  [T]  (W):  ~  [X]  (W}. 

The  first  set  contains  all  state  pain  in  which  the  condition  holds,  and  the  second  set  those  pain  in  which  it  does  not 
hold.  It  is  important  to  note  the  way  that  failure  of  definition  can  occur  here.  There  is  no  “evaluation"  of  these  sets 
in  any  order.  They  simply  contain  or  fail  to  contain  certain  pans.  For  example,  should  |  E  |  fail  to  be  defined  for 
some  V,  that  U  will  not  occur  in  the  second  set,  independent  of  |  B  |  .  Such  a  failure  has  no  influence  whatsoever  on 
pain  in  the  first  set.  However,  failure  of  |  B  |  is  another  matter.  If  this  function  fails  to  be  defined  for  some  U, 
neither  condition  bolds,  and  U  is  not  paired  with  anything  in  either  set;  that  is,  [T]  is  undefined  for  such  a  U. 

The  IF-statement 

IF  B 
THEN 

T 

could  be  given  a  similar  definition,  but  it  can  also  be  agreed  to  mean  the  same  as: 

t  F  B 
THEN 

T 

ELSE 

{null  statement} 

so  dud  its  definition  can  be  derived  as  follows: 


I F  B  THEN  T  |  (U)  = 


□D  (U)  if  (X]  «/> 

u  if  ~  m  (t/> 

otherwise  undefined 


or,  in  the  functional  notation: 


I  IF  B  THEN  T  |  = 

{(£/,V):  [~g~|  (!/)  and  V  =  (TJ  (10) 

U  {(I/,  U):  -  [T]  (*/)}■ 

In  the  second  case,  the  identity  function  is  applied  to  the  state,  since  that  is  the  meaning  of  the  null  statement. 


6.2  Analysis  of  Conditional  Statsmsnts 

Composing  die  functions  that  result  from  IF-state merits  is  no  more  difficult  in  principle  than  composing 
imperative- statement  functions,  but  the  notations!  complication  is  even  more  severe.  The  trace  table  can  be  extended 
to  help  in  practical  cases.  A  conditional  trace  table  has  an  additional  column  of  conditions  expressed  in  terms  of  the 
values  in  the  table,  namely  the  conditions  required  for  the  assignments  in  the  table  to  take  place.  For  example,  the 
program  part  5: 
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BEGIN 

IF  VI  <  V8 
THEN 

VI  : *  VS 
ELSE 

V8  :■  V3; 
VI  :  *  V3; 

IF  va  <  V3 
THEN 

VB  :*  V3 
ELSE 

V3  : *  VI 


will  execute  in  one  of  four  sequences,  depending  on  which  of  the  THEN  or  ELSE  statements  of  the  two  EF-statements 
are  selected.  Identify  these  sequences  by  noting  T  or  E  for  the  THEN  or  ELSE  alternatives  in  order,  so  S(T.T)  means 
the  two  THEN  parte  are  taken,  while  5(E,T)  means  that  the  first  ELSE  is  taken,  then  the  second  THEN.  This  gives  a 
conditional  trace  table  such  as: 

SCT.T) 

if  vi  <  va 

THEN  VI  :■  V8 
VI  :«  V3 
IF  V8  <  V3 
THEN  V8  :«  V3 

The  auhecripts  of  a  condition  refer  to  the  vetoes  of  the  previous  line,  since  the  condition  is  evaluated  at  the  beginning 
of  the  staSemrut.  An  ordinary  assignment  has  the  coodrdoo  hue.  For  this  particular  sequence  to  be  executed,  every 
ibhi  imld,  bo  lbs  condition  fof  die  sequence  is  the  conjunction  of  the  conditions  in  the  table.  Eliminating 
iOQiQnii(  UB8  cononxm  mi 


Condition  VI  V2 

Vl0  <  V2o 

Vl,-V2o 
true  Vlj-V3, 

V2,  <  V3j 

V2,*V32 


(Vlo  <  V2o)  and  true  id  (V2o  <  V3o) 

(since  V2j«V2o  and  V3j-V3o  from  the  trace  table)  and  the  equations  that  result  are: 


Vlj  -  V3*  V2,  -  V3o.  V3,  -  V3®. 

Thus  the  meesiiag  in  the  caae  S(T,T)  is  the  set 


HU. 


Similarly,  we  find 

if  vi  <  va 
THEN  VI  :■  va 
VI  :»  V3 
IF  V8  <  V3 
ELSE  V3  :•  VI 

from  which  we  deduce  the  condition: 


Condition  VI 

Vlo  <  V2o 

VI,-V2o 

Vl2-V3, 

V2j>  V3, 


V3 


V3j*V12 


(Vlo  <  V2o)  sod  (V2o  >  V3o) 
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IB 


Vlj  -  V3o,  V3,  -  V3o 
so  that  the  meaning  in  this  case  is: 


{( V.  I  VI  ;  ■  V3  I  (I/)): 


Vi  <  va  I  ( U)  and 


va  >=  vs  1  (l/)}. 


The  case  5(E,T)  cannot  occur  (the  conditional  trace  table  leads  to  an  empty  meaning  set);  a  similar  analysis  for  case 
S(E,E)  yields  a  third  set.  and  their  union  is  the  meaning  of  5: 


-  {( v , 

1  VI  : 

•  V3: 

< 

10 

ii 

V3~1  (£0): 

1  vi  <  va 

]  (U)  and  [va 

A 

< 

U 

s 

U  {(£/, 

1  VI  : 

:=  V3 

m: 

E 

A 

W 

|(10  and 

1  va  >=  v3 

\(U)} 

U{(1/, 

1  VI  ■ 

:*  V3; 

va  :  = 

V3  1  (£/)): 

I  vi  >*  va  1  (to). 


2? 


t  vnrmon  ounvcnonu 

With  iteration-free  programs,  we  have  seen  how  to  derive  program  meaning  as  a  composition  of  the  meaning  of 
program  parts,  in  which  die  number  of  parts  is  determined  by  the  static  program  text.  However,  with  iteration, 
program  parts  can  be  executed  repeatedly.  If  the  number  of  iterations  were  fixed,  the  part  functions  would  be  fixed 
compositions  of  simpler  part  functions.  But  the  great  power  of  iteration  statements  arises  from  a  variable  number  of 
iterations,  so  we  need  not  be  surprised  that  the  difficulty  of  dealing  with  iteration  statements  increases  accordingly. 

Although  in  a  long  iteration-free  program  there  could  be  a  great  deal  of  notational  difficulty  in  calculating  the 
program’s  meaning  function,  there  is  no  difficulty  in  principle:  each  statement  has  its  functional  meaning,  and  the 
meaning  of  the  whole  is  simply  their  composition.  There  is  no  mechanical  way  to  deal  similarly  with  iteration 
statements,  but  this  section  presents  a  definition  of  meaning,  and  techniques  for  proving  that  a  loop  has  a  certain 
meaning,  which  must  be  (nomnechanically)  guessed  or  supplied  independent  of  the  program  text. 


7.1  MMnlng  of  Iteration  Stetemanta 


The  power  of  iteration  exacts  a  high  price  when  it  comes  to  calculating  the  meaning  of  WHILE-statements.  The 
pattern  of  our  definitions  has  been  to  give  the  function  of  each  statement-type  in  terms  of  its  parts.  The  parts  of  a 
WHUJE-statement  are  evidently  the  condition  (determining  if  the  iteration  should  continue)  and  the  loop  body  (what  to 
do  if  it  should  continue).  The  difficulty  is  that  the  action  of  the  loop  body  is  repeated  in  forming  the  meaning  of  the 
loop  as  a  whole,  and  this  repetition  occurs  a  number  of  times  that  is  not  explicit  in  the  text.  If  the  number  of  times  k 
the  iteration  occurs  were  known,  there  would  be  a  way  out  of  the  difficulty,  for  then  die  function  of  the  entire 
WHILE- it atcmrnt  would  be  a  composition  of  its  body’s  function  exactly  k  times.  For  example,  if  it  were  magically 
given  that 


WHILE  B  DO D 

“went  around"  exactly  twice,  then  we  could  consider  it  equivalent  to 
BEQIN0;  D  END 


.  * 


would  he 

r.  !f.  w.  •. 


.  »   . 


> 
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ILE  B  00  D 


I  D.  D 


There  is  yet  a  further  complication  in  defining  the  semantics  of  the  WHILE-statement.  It  may  happen  that  the  loop 
never  terminates.  In  that  case  the  “number  of  iterations”  makes  no  sense,  and  the  function  of  the  loop  is  undefined 
for  die  state  that  caused  the  unlimited  repetition.  The  number  of  iterations  to  completion  is  in  all  cases  the  key  to  the 
WHILE-statement .  If  this  number  is  k,  then  the  function  of  the  loop  is  Mold  composition  of  the  function  for  the  loop 
body;  if  the  iteration  continues  without  end,  the  function  is  undefined. 

There  is  a  direct  way  to  capture  the  function  of  a  loop,  by  asserting  that  the  state  resulting  from  the  loop’s 
execution  is  die  result  of  the  loop  body  executing  k  times,  for  some  unspecified  k.  To  be  consistent  with  the  intuitive 
meaning  of  the  loop,  this  k  (if  it  exists)  has  the  property  that  the  loop  condition  is  true  before  the  1st,  2nd,  ...  Jfeth 
iteration,  then  is  fake.  That  is,  after  k  iterations  the  condition  fails  for  the  first  time.  The  WHILE-statement  meaning 
therefore  consists  of  exactly  those  ordered  pairs  for  which  there  is  the  appropriate  k,  with  the  output  state  being  a 
Mold  action  of  the  loop  body  on  the  input  state. 

The  definition  of  meaning  along  these  lines  will  now  be  given.  Let  WHILE-statement  W  be 


WH I  LE  B  OO 
D 


where  His  a  Boolean  expression  and  D  is  a  statement.  Then  define 


|  wl  ”  {(T,  U):  Ik  integer,  k  >  0 
V  i  integer,  0  <  i  <  * 

( in  ( foi  '(D) 


~  [!]<□□*< D) 

and 

f~P~l*(7)  ”  U)l 

For  example,  consider  the  loop  U: 

WHILE  VI  >  ' 1 '  DO 
IF  VI  *  *8'  THEN 
VI  :■  ’O' 

ELSE 

IF  VI  »  '9'  THEN 
VI  ’1' 

ELSE 

VI  : -  SUCCCSUCCtVI ) ) 


Suppose  that  die  value  attached  to  Vi  in  the  input  state  for  U  is  x.  How  many  times  k  will  die  loop  be  repeated?  If  x 
<  1,  then  k  «  0.  If  x  is  a  digit,  then  k  “  (10-x)/2  rounded  up  to  die  nearest  integer.  (For  example,  if  x  =  8,  then 
(I0-9V2  ■  1/2  or  rounded  up,  A  «  1;  if  x  -  3,  then  (10-3y2  *  7/2,  or  *  =  4,  etc.  It  is  clear,  however,  that  vi  will 
end  up  1  or  0,  without  the  necessity  of  determining  k  exactly.)  If  x  >  8,  after  a  number  of  iterations  roughly  half  the 
<Bstaiacas  from  x  to  the  end  of  the  character-order  subsequence,  the  meaning  of  the  SUCC  expression  will  be  the 
undefined  function.  This  in  turn  causes  the  assignment  statement  to  mean  the  undefined  function,  and  this  means  that 
in  the  definition  of  the  WHILE-statement  there  is  no  Mor  the  case  x  >  8.  Thus  the  meaning  of  the  loop  U  is: 
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nn  =  {(7\  7):  T(vi)  <  1} 

U  {(T,  A):  1  <  7T(V1)  <  ®  and 

A  is  the  same  as  T  except 
that  A(vi )  is  ‘J  or  I  as 
r(vi )  is  an  odd  or  even  digit}. 


7.2  Analysis  of  Iteration  Statements 


When  the  number  of  iterations  cannot  be  easily  determined,  the  loop  controlled  by  the  WHILE-statement  cannot  be 
easily  unwound  as  its  loop  body  acting  over  and  over.  But  it  can  always  be  unwound  into  the  first  time  the  body 
acts,  and  then  the  rest  of  die  times,  if  that  first  execution  is  guarded  by  a  test  to  cover  the  case  that  the  loop  doesn’t 
execute  at  all.  That  is, 

WH I  LE  B  DO  D 
is  equivalent  to 

BEGIN  IF  B  THEN  D;  WHILE  fi  OO0  ENO. 

The  equivalence  can  be  seen  by  examining  cases.  First,  suppose  the  original  loop  body  D  is  never  executed  (because 
condition  B  fails  immediately).  Then  in  the  expanded  version  the  IF  condition  similarly  fails,  so  the  broken-out  body 
is  not  executed,  then  in  the  repetition  of  the  loop  itself  the  condition  B  fails  again,  so  the  body  is  again  not  done. 
Thus  the  two  programs  agree  in  this  case.  Secood,  suppose  the  original  loop  in  fact  executed  its  body  exactly  once. 
Then  the  condition  initially  succeeds,  but  something  in  die  body  causes  it  to  fail  when  tried  a  second  time.  In  the 
expanded  version  exactly  die  same  behavior  is  observed,  with  the  IF  condition  succeeding,  the  broken-out  body 
executing  and  the  repeated  WHILE  condition  then  failing.  The  remaining  cases  in  which  the  original  loop  executed 
more  than  once  are  similar,  the  broken-out  body  takes  the  first  execution,  and  the  repeated  loop  picks  up  the 
remainder. 

The  discussion  in  the  preceding  paragraph  can  be  mirrored  exactly  in  the  formal  meanings  we  have  defined,  where 
the  fanctional  meaning  far  each  of  the  code  fragments  can  be  determined,  and  “equivalence"  means  that  the  functions 
are  the  same.  The  analysis  by  cases  becomes  a  formal  induction  on  the  number  of  iterations  required  for  die  loop  to 

h  may  seem  surprising  that  this  simple  device  can  help  with  the  analysis  of  loops,  but  it  does.  The  reason  is  that 
the  repealed  loop  is  exactly  the  same  loop  as  the  original,  and  this  allows  us  to  write  an  equation  in  which  the  loop 
fanctioa  occurs  twice.  Equating  the  meaning  functions  for  the  two  loops: 


1  WHILE  B  DO  D  | 

«  I  BEGIN  I F  B  THEN  D;  WHILE  B  DO  D  ENO~l  . 

fa  die  compound  statement  of  the  secood  line  the  first  part  is  a  conditional,  and  the  meaning  of  that  can  be  worked 
out  separately: 


I  WHILE  B  DO  D  | 

-  I  IF  B  THEN  D  1  •  1  WHILE  B  DO  D  1  . 

The  fanctioa  of  the  loop  has  expikitiy  reentered  the  equation.  It  will  be  clearer  if  we  name  this  function  so  it  can  be 
easily  recognised.  Let 
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I 


IF  B  THBSI  D  1  •/, 


JtJ)  »AI  IF  B  THEN  g  |  (7)). 


This  recurrence  equation  in  function  /  is  useful  because  very  often  we  can  guess  (or  believe  a  comment  to  discover) 
what  a  program  it  wppoaed  to  do.  Then  to  prove  that  it  does  indeed  do  so,  the  guessed  function  can  be  substituted 
into  the  equation  far/.  Care  is  required  in  this  operation,  however.  The  recurrence  equation  is  one  that  die  function/ 
far  the  loop  must  satisfy;  but  it  does  not  follow  that  any  function  satisfying  the  equation  is  in  fact  the  function  of  the 
loop.  A  simple  example  will  show  the  pitfall.  Consider  a  loop  that  never  terminates: 


WHILE  'A'  *  'A'  DO  {nothing} . 

It  is  clear  that  this  WHILE-statement  has  a  function  that  is  empty~it  contains  no  ordered  pairs  because  the  loop  does 
not  terminate  on  any  input.  But  the  recurrence  reduces  to 


/-/ 

for  this  loop,  since 


I  IF  * A1  ■  'A*  THEN  {nothing)  | 

is  the  identity  function.  Any  function/ satisfies /  ■/,  yet  all  save  the  empty  function  are  wrong  for  the  loop. 

The  remedy  for  this  problem  is  to  add  conditions  which  rule  out  such  extraneous  solutions  to  the  recurrence 
equation.  One  obvious  condition,  in  view  of  the  pitfall  above,  is  to  ensure  that  die  function  is  not  defined  when  the 
loop  fails  to  terminate.  That  is,  far/to  be  the  loop  function  requires  that 

domain#)  Q  dnmam(  I  WHILE  B  DO  D  I ). 

Another  pitfall  is  shown  by  the  loop: 

WHILE  'A'  <>  'A'  DO  {nothing}. 

In  this  case  the  WHILE-statement  has  a  function  that  is  the  identity  function;  it  acts  as  a  null  statement.  But,  again. 


IF  'A'  O  'A*  THEN Jnothli 


is  the  identity  ftmction,  the  recurrence  equation  reduces  to 

/-/ 

and  any  ftmction  satisfies  the  equation.  All  but  the  identity  function  are  wrong  for  the  loop,  however.  Many 
ftmctions  satisfy  die  domain  constraint  developed  above  as  well;  but,  all  except  the  identity  function  violate  another 

—  —  m — .  ^ an 

OTBUt  CB0GK0Q  vtilnflinrll  WIICB  D  VHJH  DO*  DOM* 


JU)-T 


~  rri(D. 


Happily,  just  dmee  two  additional  conditions  are  sufficient  to  ensure  that  an  /  satisfying  the  recurrence  equation  is 


(Wim  B  stassmant  Verification) 


/•  .N  A  *•  A  A  *.  A 
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W  =  WHILE  fl  DO  D. 

Then 

/=  m 

if  and  only  if: 

1.  domain!/)  Q  domain!  I  W  | ) 

2.  fiT)  —  T  whenever  ~  |  B  |  (T) 

3.  fiT)  =  fi  I  IF  B  THEN  in  (D). 

Proof.  First,  suppose /  =  |  W  |  .  Then  conditions  1.-3.  must  be  established. 

1.  domain(/)  C  domain!  1  W  [ )  because/and  1  W  |  are  the  same  function. 

2.  Suppose  ~  |  B  |  (T)  for  some  T.  Then  |  VP  |  (T)  =  T  by  definition,  and  hence  since  /  =  m  ,  we  have  fiT) 
T  as  required. 

3.  It  has  been  argued  above  that 
|  WHILE  B  DO  D 

*  I  I F  B  THEN  D\  WH I  LE  B  DO  D  1 
and  by  definition  of  composition  and  W  this  is 

□E]!D=  HHfl  IF  B  THEN  D  1(D), 

so  the  same  equation  follows  for  /,  since  /  =  |  IV  |  . 

Conversely,  suppose 

1.  domain!/)  £  domain!  I  W  | ) 

2.  fiT)  *  T  whenever  ~  [T]  (T) 

3.  fiT)  *  fi  1  if  B  THEN  Pi  !7)). 

Then,  we  will  show  that 

/-  ran. 

Let  T  be  any  member  of  domain!/).  Then,  by  1.,  T  is  a  member  of  domain!  I  W  | ).  That  is,  |  while  B  DO  D 
defined  for  input  state  T.  Therefore,  by  definition  there  exists  a  k  (depending  on  T)  such  that 

fXl  (  Pol  *(D)  is  false, 
but  for  each  0  <  i  <  k-l, 

fal  (  O  '(7))  is  hue. 

Then  in  hypothesis  3,  substitute  *-l  times  for  f 


fiT)  mA  I  IF  B  THEN  D\  (7)) 

-  fi  I  IF  B  THEN  D  I  (  |  IF  B  THEN  D  (T))). 


'  fi  I  IF  B  THEN  D  1  H.T)) 

the  associativity  of  composition.  From  the  definition  of  the  conditional,  this  is 
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AT)  »  A  1"5"1  k<T)) 

since  each  of  the  evaluations  is  at  a  state  whete  is  true.  On  the  right  side  of  this  equation,  the  state  is  one  in 
which  pTI  is  false,  so  by  hypothesis  2,/ does  not  alter  this  state.  Thus 

AT)  =  1~P~1  HT), 

and  by  definition  of  the  loop  terminating  after  k  iterations, 

n*n  =  foi*. 

so  /  =  |  W  1  .  QED 

For  example,  consider  the  WHILE-statement  U  of  the  last  section: 

WH I LE  VI  >  ' 1 '  DO 
IF  VI  =  '8'  THEN 
VI  :=  'O' 

ELSE 

IF  VI  =  '9'  THEN 
VI  : =  '  1  ' 

ELSE 

VI  :  =  SUCCCSUCCtVI J ) 
whose  function  was  claimed  to  be: 


/  =  {(7\  T):  7Xvi )  <  1} 

U  {(T,  A):  1  <  7TV1)  <8  and 

A  is  die  same  as  T  except 
that  j4(vi  )  is  *1  or  S  as 
7XV1)  is  an  odd  or  even  digit}. 

To  prove  this  using  the  WHILE-statement  verification  theorem  we  must  show: 


1.  domain#)  Q  domain!  1  U  [ ) 

2.  AT)  =  T  whenever  ~  |  VI  >  1 2 3 1~ 

3.  AT)  =  A  I  l  F  VI  >  '  1 '  THEN  £> 


(T) 

<T», 


where  D  is: 


IF  VI  =  'S'  THEN 
VI  : =  'O' 

ELSE 

IF  VI  =  'S'  THEN 
VI  : =  '  1  ' 

ELSE 

VI  : *  SUCCCSUCCtVI J ) 


1.  The  domain  of  fit  evidently  {c:  c  <  ®}.  The  program  evidently  terminates  on  vi-values  of  S  and  \  and  for 
values  of  vi  less  than  1.  On  the  remaining  digits  the  program  advances  along  the  sequence  toward  ®  or  r  by  two 
steps,  and  so  must  hah. 

2.  Immediate  from  the  definition  of  /. 

3.  Consider  two  cases  for  the  data  state  T: 

If  7TV1)  <  1,  then  the  box  function  of  the  conditional  is  the  identity,  and  3.  holds. 
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If  T(Vi)  >  ,  then  the  conditional  box  function  is  just  [  D  j  ,  so  we  require  fi D  =  f{  [  D  \  (T)),  and  this  is 
evidently  so  by  an  analysis  of  the  cases  ; ,  and  -  ,  since  the  double  SUCC  preserves  even-  and  oddness. 

This  calculation  of  the  meaning  of  a  simple  WHILE-statement  illustrates  a  difference  in  the  program  calculus  from 
the  calculations  of  Sections  4  and  6.  For  iteration-free  code,  the  meaning  of  programs  can  be  mechanically 
calculated,  using  the  rules  given  in  those  sections.  For  WHILE-statements  things  are  not  so  nice,  it  is  necessary  to  be 
given  or  to  guess  the  meaning,  then  verify  that  the  guess  is  correct.  The  situation  is  appropriate  to  the  power  of 
iteration.  In  practice,  finding  a  trial  function  on  which  to  use  the  WHILE-statement  verification  theorem  is  not  a 
problem.  A  helpful  comment  often  supplies  one,  or  intuitive  understanding  of  the  code  can  be  used  to  work  one  out. 
Once  a  guess  is  in  hand,  the  program  calculus  establishes  that  it  is  or  is  not  correct,  with  rigor  equal  to  that  used  to 
derive  the  functions  of  the  simpler  constructions. 


8  Procedures 

The  meaning  of  CF  Pascal  procedure-call  statements  should  be  easy  to  define,  since  a  procedure  body  consists  of 
statements  whose  meaning  has  already  been  given,  (if  the  body  contains  procedure  calls,  the  definition  should  close 
at  this  point.)  Three  ideas  complicate  the  picture: 

(1)  Procedures  have  local  variables,  whose  names  may  conflict  with  other  variables  in  the  program.  They  may 
make  use  of  global  variables  from  an  environment  different  than  the  one  existing  at  the  point  of  call.  In  technical 
terms,  the  data  state  for  a  procedure's  body  may  be  quite  different  from  the  data  state  existing  before  and  after  its 
call. 

(2)  Procedures  have  parameters  (called  by  strict  reference  in  CF  Pascal),  which  behave  partly  as  local  variables 
subject  to  the  difficulties  of  (1)  above,  and  partly  as  links  into  the  calling  environment.  In  the  latter  r  -c  the 
problem  of  aliasing  must  be  handled:  apparently  distinct  parameter  variables  may  be  a  single  called  variable 

(3)  Procedures  may  be  called  recursively,  introducing  repeated  instances  of  problems  of  (1)  and  (2)  above,  and  the 
further  difficulty  that  the  meaning  of  a  call  may  be  defined  in  terms  of  another  call  on  the  same  procedure. 

These  complications  can  be  handled  by  small  changes  in  the  data-state  notation,  and  by  a  device  based  on  the  ALGOL 
60  "copy  rule"  [1|. 

In  outline,  the  meaning  of  a  procedure-call  statement  is  the  meaning  of  the  procedure  declaration.  The  procedure 
header  plays  a  role  similar  to  that  played  by  the  program  header:  it  transforms  the  data  state  from  the  one  at  call  to  the 
one  needed  for  the  body,  and  after  the  body's  meaning  has  been  obtained,  the  calling  data  state  is  restored.  Some 
adjustments  are  necessary  to  handle  variable  conflicts  between  the  calling  and  called  data  state.  But  except  for  these 
technical  details,  the  bulk  of  procedure-call  meaning  is  simply  the  meaning  of  the  statements  in  the  declaration,  most 
of  which  are  those  defined  in  Sections  4,  6,  and  7.  When  a  procedure  call  occurs  within  a  procedure  body  there  is  no 
difficulty-the  definition  is  simply  applied  again  and  eventually  a  lowest  level  is  reached  in  which  there  are  no  more 
calls— unless  the  call  is  recursive. 


8.1  Procedure  Statement  Meaning 

The  meaning  of  a  procedure  call  in  a  data  state  T  (the  calling  state)  is  the  meaning  of  the  procedure  s  declaration  in 
that  state.  Within  a  procedure  declaration  the  only  syntax  that  has  no  defined  meaning  (once  procedure  statements 
have  been  defined)  is  the  procedure  header.  We  let  the  meaning  of  the  header  be  a  mapping  that  properly  alters  the 
data  state  to  account  for  the  procedure's  parameters.  Imagine  that  a  variable  A  is  passed  as  actual  parameter  for  a 
formal  parameter  X.  Then  we  wish  to  augment  the  calling  data  state  by  attaching  X  to  whatever  value  A  is  attached  to 
there,  and  maintain  this  identification  of  X  and  A  so  long  as  the  called  procedure  is  active  A  good  notation  pairs 
these  two  identifiers  with  the  value  For  example,  if  the  procedure  declaration  were 

PROCEDURE  Pro (VAR  PI  CHAR) 

and  were  called 


8.1  Procedure  Statement  Meaning 


25 


ProtVnl ) 

in  the  calling  data  state 

(...,  Va l ...), 

then  the  modified  state  would  be 

(...,  (Va  l ,  Pi )*Z,  ...). 

Formally,  this  change  is  difficult  to  make.  The  data  state  is  no  longer  a  mapping  from  identifiers  to  values.  If  its 
domain  is  instead  taken  to  be  sets  of  identifiers,  and  V  occurs  in  one  such  set  in  state  T,  then  the  definitions  must  be 
adjusted  so  that  T\V)  is  the  value  attached  to  that  set.  Similarly,  in  the  meaning  of  assignment  and  READ- statements, 
values  must  be  attached  to  the  sets  in  which  the  identifier  acquiring  a  value  occurs.  Without  making  the  formal 
changes  to  data  states,  we  will  use  the  notation  in  which  sets  of  identifiers  are  associated  with  a  value,  and  suppose 
that  the  box  function  of  an  identifier  results  in  the  value  attached  to  the  proper  set. 

For  simplicity  in  defining  the  meaning  of  a  procedure  header,  consider  a  single  parameter.  If  the  declaration  is 
PROCEDURE  RoutVJ; 

B 

where  A  is  the  complete  text  of  the  definition,  then  the  meaning  of  a  procedure  statement 


(T) 

is  a  state  U  the  same  as  T  except  that  V  is  paired  with  A  in  its  identifiers,  both  taking  the  value  |  A  1  (D  in  U.  The 
inverse  of  this  mapping  undoes  this  data- state  transformation:  the  value  that  was  attached  to  the  set  containing  V'  and  A 
is  restored  to  A  alone.  Thus,  the  meaning  of  a  procedure  call  is  to  alter  the  calling  data  state  to  include  the 
parameters,  carry  out  die  meaning  of  the  procedure’s  statements,  then  restore  the  calling  identifiers,  some  of  whose 
values  may  have  changed. 


8.2  ktenttfter  Conflicts  and  Local  Variables 

in  pathological  cases,  the  parameter  identifiers  added  to  the  calling  state  by  the  procedure  header  may  conflict  with 
ideittiften  already  in  that  stale.  Should  this  happen,  it  is  the  former  that  should  give  way  to  establish  the  meaning  of 
CF  Pascal.  Similarly,  within  the  body  of  a  procedure  there  are  local  vap  declarations,  and  according  to  the  semantics 
given  in  Section  4.2  these  modify  the  state.  Should  there  be  a  conflict  in  identifiers,  these  local  variables  must  give 
way  as  well.  A  mechanism  for  resolving  identifier  conflicts  was  invented  for  just  this  purpose  in  ALGOL  60.  as  a 
part  of  the  “copy •rule'’  definition  of  procedure  meaning,  and  we  adopt  it. 

Whenever  a  state  is  altered  in  defining  the  meaning  of  a  procedure,  each  identifier  to  be  added  is  checked  against 
thoae  already  present  in  the  state  Should  there  be  a  conflict,  the  additional  identifier  is  systematically  replaced  New 
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identifiers  are  created  by  appending  i  to  the  original  one  until  a  nonconflicting  name  is  created.  This  new  identifier  is 
then  substituted  throughout  the  text  for  the  original,  before  the  state  is  changed.  Thus  the  new,  unique  identifier 
enters  the  state,  and  the  program  text  whose  meaning  is  being  defined  contains  that  new  identifier  whenever  it  should 
to  preserve  the  original  intent. 

A  notation  for  the  systematic  substitutions  required  to  avoid  identifier  conflicts  is  more  trouble  than  it  is  worth.  We 
will  assume  the  necessary  changes  have  been  made,  and  make  them  in  examples.  Where  possible  the  original  choice 
of  identifiers  will  be  made  to  avoid  conflict.  (But  in  recursive  procedure  calls  this  may  be  impossible;  see  Section 
8  3.) 

The  meaning  for  VAR  declarations  given  in  Section  4.2  adjusts  the  data  state  to  add  the  newly  declared  identifier. 
In  the  VAR  declaration  of  a  PROGRAM  there  is  no  need  to  later  remove  this  identifier,  because  it  ceases  to  have 
meaning  only  when  the  program  is  complete,  and  there  the  terminating  period  extracts  only  the  file  strings  from  the 
data  state.  However,  the  VAR  declarations  within  procedures  are  different.  Their  identifiers  must  exist  only  as  a  part 
of  the  meaning  of  a  call,  must  not  persist  following  the  call.  The  relation  given  as  meaning  for  a  var  declaration  has 
an  inverse  with  just  the  properties  needed:  it  maps  a  state  containing  the  new  var  and  its  value  (if  any)  back  to  one  in 
which  the  variable  does  not  appear.  Thus  for  a  declaration  followed  by  a  block: 

D  =  VAR  V 
BEGIN 


the  meaning  is 


VAR  V  I  *  I  BEGIN  . . .  END 


As  an  example  of  a  procedure  call,  consider  the  program: 

PROGRAM  Pr2t INPUT.  OUTPUT); 

VAR 

Next:  CHAR; 

PROCEDURE  Col  I ectVC FI  eg:  CHAR); 

VAR 

Next:  CHAR; 

BEGIN 

Next  :=  'B'; 

Fleg  : =  'T* 

ENO; 

BEGIN  { Pr2 } 

Next  :*  'A'; 

Co! lectV(Next) 

ENO. 

When  the  procedure  call  that  ends  Pr2  occurs,  the  data  state  (for  input  string  x)  is: 


(  I  NPUT*jr,  OUTRjT*_,  Next**). 

Since  this  example  it  not  concerned  with  i  nput  and  Output,  in  the  sequel  they  will  be  omitted  from  the  state  to 
simplify  the  notation. 

The  call  on  Co  i  i  ectv  has  the  meaning: 
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2 ; 


1  Col  IsctVtNext)  1  ((Next*A)) 


PROCEDURE  CojJjctVtFjsfr:  CHAR); 


VAR 


ENO  I  ((Next**)) 


PROCEDURE  Col lectVtFleq:  CHAR)  1  1 
(  |  VAR  Next:  CHAR;  BEGIN  ■  .  .  ENO  |  (((Next,  FIuq)*A))) 


I  PROCEDURE  Col  lectVtFleq:  CHAR)  1  '(  VAR  Next  I  :  CHAR 
(  I  BEG  I N  Next  I  :  = 


ENO 


(((Next,  F I  eg)*A,  Next  l  •?)))). 


Working  out  the  meaning  of  the  body  itself  is  straightforward: 

I  BEGIN  Next  I  END] 

(((Next,  F l  eg)*A,  Next  i *?)) 

*  ((Next,  F  l  eg)*7.  Next  I  *8). 


so  the  result  is 


|  PROCEDURE  Cot IsctVtFlep:  CHAR)  1  ''(  I  VAR  Next  I  :  CHAR  j  *• 
(((Next,  F I  eg)*7,  Next  I  *8))) 

«  (Next*?). 


Here  is  an  example  program  P  on  which  many  students  of  Pascal  (and  many  early  compiler-writers  as  well)  have 
foundered: 

PROGRAM  Confueedt INPUT.  OUTPUT J  ; 

VAR 

Which:  CHAR; 

PROCEDURE  Zep; 

BEGIN 

Which  :*  'Z'  { Zep  It.  but  which?} 

ENO; 

PROCEDURE  Inelde; 

VAR 

Which:  CHAR; 

BEGIN 

Which  :*  'B'; 

Zap; 

WRITECWhlch) 

END; 

BEGIN  {Confused} 

SWiieh  :-  'A'; 

Inside; 

WRITE (Which) 

ENO. 

This  program  “Ze p”s  one  of  its  Wh  i  ch  vars,  but  which  one?  Is  the  meaning 

m  (r)  *  za 


or 


rri  (n  - «? 

(The  answer  can  be  guessed  by  imagining  a  change  of  var  names.  Suppose  the  wh  i  ch  within  procedure  Zep 
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were  some  different  name.  Then  Zap  would  not  have  correct  syntax:  this  different  name  would  not  be  declared,  and 
VAfl  names  within  I  na  I  da  would  be  of  no  help.  This  goes  along  with  the  meaning  being  \~F\  (/)  =  $Z.) 

Using  the  definition  at  the  point  of  the  call  on  I  na  i  da: 


(  me  Ida  |  ((OUTPUT*  ,  wn  i  ch*A)) 

1  ■'(  |  VAP  Wh i ch i :  CHAR- 


Inali 


ENO 


(  |  PWOCB3URE  Irtaida  |  ((OUTPUT*_,  Wh  i  ch*1 )))). 


Both  1  PR0C6QURE  Inal  da  I  and  its  inverse  are  the  identity  function,  since  there  are  no  parameters,  so  we  have: 

*  |  VAR  Which!:  CHAR~|  '(  |  BEGIN  Which!  ;  =  '  B '  ;  Zap;  ...  END~1 
((OUTPUT*  ,  Wh  i  ch*A,  Wh  i  ch  i  •?)))) 


*  |  VAR  Wh  I  ch  I  :  CHAR~T  '(  1  Zap;  WPITE(Whichi)  ENO  1 
((OUTPUT*  .  Wh  I  ch*A,  Wh  i  ch  i  *B)))). 

Because  Zap  has  neither  parameters  nor  VARs,  the  data  state  remains  the  same  when  its  body  meaning  is  applied: 

=»  |  VAR  Wh  I  ch  t  ;  CHAR~|  *' 

(  |  WR I TE  (Wh  1  ch i  )  |  (  |  BEG  IN  Which  :  =  '  Z '  ENO  | 

((OUTPUT*  .  Wh  i  ch*A,  Wh  i  ch  i  •#)))) 

* 

-  |  VAR  Which}  CHAB~j  '' 

((OUTPUT*®.  Wh  I  ch*Z.  Wh  i  ch  i  *«)) 

-  (OUTPUT*#  ,  Wh  I  ch*Z). 

From  here  it  is  easy  to  calculate  dun  1  P  |  (/)  -  II. 


8.3  Rtcwion 


When  a  procedure  call  occurs  within  a  procedure  there  are  just  two  possibilities:  either  this  call  and  others  that  it  may 
lead  to  eventually  come  down  to  a  procedure  body  in  which  no  calls  occur,  or,  one  of  the  procedures  in  the  potential 
chain  of  calls  has  occurred  previously  in  the  chain.  These  alternatives  are  a  consequence  of  the  finite  nature  of 
programs:  unless  one  of  the  procedures  is  recalled,  the  list  of  all  possibilities  must  soon  be  exhausted  When  a 
procedure  ends  up  being  reinvoked,  it  is  said  to  be  called  recursively. 

The  consequence  of  blindly  applying  the  definitions  given  earlier  in  this  section  to  a  nonrecursive  call  sequence  is 
happy:  a  definition  of  the  meaning  of  the  whole  program  results  without  difficulty.  Similar  application  to  a  recursive 
sequence  is  test  satisfactory:  it  results  in  a  recurrence  relation  in  which  the  function  computed  by  the  recursive 
procedure  is  defined  in  terms  of  itself.  As  a  simple  example,  consider  the  program: 
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PROGRAM  TMtOddt  INPUT.  OUTPUT); 

jRiada  on*  oharactar  from  INPUT  and  raturna  Y(aa)  or  N(o) 
dapandlng  on  wHaeHar  or  not  it  ia  odd.  Tha  action  ia  not 
daf  triad  if  INPUT  ia  ampty  or  tha  f  i  rat  character  ia  not 
a  digit. } 

VAP 

Ona:  CHAP; 

PPOCEOUPE  OddCPaault.  Val :  CHAP); 

VAP 

NaxtVal ;  CHAP; 

BEGIN 

IP  Val  *  '8'  THEN 
Paaul t  : ■  ' Y' : 

ELSE 

IF  Val  «  '8'  THEN 
Paaul t  : *  'N' 

ELSE 

BEGIN 

NaxtVal  :»  8UCC ( 8UCC ( Va I ) ) : 

OddCPaault.  NaxtVal) 

ENO 
END  {Odd} 

BEGIN 

PEAOCOnal; 

Odd (Ona.  Ona); 

MPITE(Ona) 

ENO. 

Applying  the  rales  puKded  above  to  the  call 
Odd (Ona.  Ona) 
near  the  end  gives 

I  Odd  (Ona,  Ona)~|  (D 

T  except  that  Ona  has  vaioe  Y  if  7T0na)  “  I 
■  T  except  that  Ona  has  value  N  if  7\Orm)  -  8 
1  PROCEDURE  Oddt  ■  ■  T1  '(  (  OddCPaault,  NaxtVal)  |  (t/))  otherwise. 

wham  U  is  a  stale  ia  which  Beau  1 1  sad  Va  i  ate  both  grouped  with  Ona  from  T,  sod  with  Nextva  i  added,  having 
dks  vahw  two  characters  ia  sequence  beyond  the  value  attached  to  Ona  in  T. 

This  form  is  remiss  srent  of  the  situation  that  arose  in  defining  the  meaning  of  a  WHILE- statement:  the  meaning  is 
given  in  tanas  of  itself  (using  a  modified  state),  bat  with  additional  cases  that  are  not  recursively  defined,  "protecting" 
dte  recursive  cans.  For  the  WHILE-statement  the  protection  came  from  the  loop  test,  and  the  form  of  the  recurrence 
was  siaapty  related  to  the  loop  body;  here  them  elements  depend  entirely  on  the  form  of  dte  procedure  body.  That  is. 
dm  cam  of  recursive  procedure  calls  is  much  less  standardired  than  the  cam  of  WHILE-statemeats. 

Ohm  any  particular  data  vector  T,  the  definition  for  the  meaning  of  a  recursive  call  can  be  "unwound"  until  the 
reunion  tanaiaates,  if  that  happens.  And  if  it  does  not  terminate,  beginning  the  process  of  unwinding  may  expose 
dret  fact.  For  example, 

I  Odd  (One,  Qnn)*1  (On#*d)  ■  (OnwW) 


drown  above. 


However,  solving  the  recurrence  equation  in  the  general  case  is 
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8  3  Recursion 


Imagine  substituting  a  guess  for  the  meaning  of  Odd  info  the  recurrence  equation.  The  parameters  pla\  special 
roles,  literally  that  of  parameters,  in  that  the  data-state  transformation  is  different  when  they  assume  different  values 
If  we  believe  the  comments  on  the  program,  the  meaning  of  Odd  for  parameters  (identifiers)  x  and  \  is  the  function  f. 

f  =  \(T.  U)  V  =  T.  except  that 

U(x)  =  if  T(v)  is  an  odd  digit,  ami 
U(x)  =  **  if  T\y)  is  an  even  digit}. 

(The  implication  is  that  if  7\y)  is  not  a  digit  at  all.  there  is  no  second  element  of  the  pair  in  this  set:  that  is.  /  is 
undefined  for  such  T  )  Substituting /  in  the  recurrence  equation,  the  left  side  is: 

T except  that  Ooa  has  value  (or  J) 
if  T(On«)  is  odd  (or  even) 

On  the  right,  the  first  two  cases  are  in  agreement  with  this  data  state  For  the  third  case,  a  digit  value  must  be  pnoi 
to  in  sequence,  and  again  substituting  f  we  get  for  |  Odd  (Beau  1 1 .  Nextva  i  )  i  (CV 

U  except  that  n«nu  i  e  has  value  (or  ) 
if  {/(Nextva  i )  is  odd  (or  even). 

But  {/(Nnxevn  i )  is  two  characters  in  sequence  past  T( One).  and  hence  is  even  or  odd  in  step,  the  application  ot  the 
header  inverse  (unction  leaves  the  Result  value  attached  to  One  in  T.  Thus  the  left  and  right  sides  of  the 
recurrence  equation  agree  for  this  /. 

To  prove  that  a  function  /  is  the  one  computed  by  a  recursive  procedure  call,  it  is  necessary  that  /  satisfy  the 
recurrence  relation:  however,  this  condition  is  not  sufficient.  Furthermore,  when  there  are  multiple  recursions  the 
situation  is  even  more  complex.  Consider  the  case  in  which  procedure  P  calls  procedure  Q  and  vice  versa,  and  P 
does  not  call  itielf.  but  0  does  call  itself.  Then  in  working  out  the  meaning  of  a  call  on  P  the  meaning  of  Q  will 
appear,  and  working  this  out  in  turn  will  yield  a  recurrence  relation  defining  Q' s  meaning  in  terms  of  itself  and  P  « 
meaning.  This  illustrates  the  general  situation:  the  result  of  analysis  will  be  a  system  of  m  simultaneous  equations  in 
m  functions,  one  for  each  procedure  involved  in  a  recursive  chain  of  calls  Substitution  may  simplify  this  system  (for 
example,  substituting  the  P  equation  into  the  Q  equation  will  eliminate  P).  but  cannot  solve  it.  It  is  evident  that  the 
caae  of  recursion  is  far  more  complex  than  the  case  of  WHILEstatements.  and  a  resnli  parallel  to  the  WHH.F 
verification  theorem  more  difficult  to  obtain. 


9.  Summary  and  ConcHisJont 


Using  a  subset  of  Pascal,  a  "program  calculus"  has  been  described  that  assigns  functional  meaning  to  programs 
For  programs  containing  no  loops  or  recursive  procedure  calls,  the  application  of  this  calculus  is  mechanical  in  the 
more  comphcaled  cases,  the  meanings  must  be  guessed  and  then  checked  For  recursive  calls,  further  work  must  be 
done  to  obtain  a  simple  checking  procedure  for  the  general  case.  To  prose  a  program  correct  for  a  specification  >n  the 
form  of  acceptable  input -output  pairs  then  becomes  an  elementary  set-theoretic  problem  Hie  specification  is  a  <et  o< 
pairs  aa  is  the  program  meaning:  the  program  is  correct  tust  in  case  its  meaning  is  a  subset  of  the  specification 
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